To be honest, this concerns me a bit as this calls for type conflicts. Imagine you get

MY_KEY=4

in a first gather cycle but

MY_KEY=3.14

in a second cycle. The very same field will be an integer in the first cycle but a float in the second cycle! This cases all sorts of issues on the output side. We've been there in the past...
I'm not sure if the issue exists for cgroups as the problem could be avoided if floats always contain a decimal separator but if that's not guaranteed I suggest to either have a named list of fields being float or to add a flag to always force fields into float (and not int).

As far as I understand the only files that have numbers with a fractional part are {cpu, io, memory}.pressure that use the PSI format.

They always have the decimal separator so in that case they will always be parsed as floats:

$ cat /sys/fs/cgroup/cpu.pressure
some avg10=0.00 avg60=0.00 avg300=0.00 total=397576165
full avg10=0.00 avg60=0.00 avg300=0.00 total=376593821

However, the issue you are describing could also happen for values that have "max" as the default but are otherwise ints... In that case what would be a good alternative to the "max" string? Maybe math.MaxInt64?

Are fields with the max string always of the integer type? If so, math.MaxInt64 would be the best way to go. For the PSI/float metrics, it seems like they always contain the decimal separator (e.g. 0.00) so this should be good. Maybe add a comment to the code for the next one stumbling upon this?